Method and device for codec negotiation

ABSTRACT

A method for codec negotiation between two gateway controllers, wherein the gateway controllers manage, in a link-independent manner, a codec list with codec types which are supported by the respective media gateway, thereby avoiding ultimate disconnection of a set-up link as a result of unsupported codecs.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is the US National Stage of International ApplicationNo. PCT/DE02/04561, filed Dec. 12, 2002 and claims the benefit thereof.The International Application claims the benefits of German applicationNo. 10163478.1 filed Dec. 21, 2001, both of the applications areincorporated by reference herein in their entirety.

FIELD OF INVENTION

The invention relates to a method for codec negotiation for a datatransmission between two media gateways and to a device related hereto.

BACKGROUND OF INVENTION

As a result of historical developments, there are two communicationsinfrastructures within most businesses. First there is theinfrastructure for data communication (LAN), and secondly there is thenetwork of private branch exchanges with the telecommunications unit incentral position.

Having separate systems is uneconomical, however, since each of thesetwo communications systems requires its own network technology. As aresult of this, it is necessary to maintain twice as much know-how tooperate and maintain the systems. Furthermore, having separate systemslike this stands in the way of the rapid development of new applicationssince the two systems are based on different technologies. Whilst thetraditional telephone network establishes in each phone call anend-to-end connection having a reserved bandwidth of 64 Kbps, in IPtelephony, speech is digitized, compressed, converted into IP datapackets and routed across the data networks together with other IPtraffic.

There is therefore a desire to bring together the two separate “worlds”with the aim of increasing the effectiveness and productivity of modernbusinesses, thus giving them a decisive competitive advantage.

In order to be able to handle real time-oriented speech applications viathe packet-oriented IP protocol, it is necessary to compress the datathat have to be transmitted. For this reason, the ITU (InternationalTelecommunications Union) has adopted a number of standards whichprovide different speech qualities irrespective of the bandwidth thatcan be used. These compression methods are also known as codecs and arehardware and/or software modules which combine within themselves thefunctions of a coder and a decoder since, when information istransmitted between two points, the transmission frequently goes in twodirections. Sometimes the codec is specially customized forcharacteristics (bandwidth, packetization period, ring tonecharacteristics) of an input signal, for example speech and/or videosignals. Practical implementation is achieved either as hardware by DSPs(Digital Signal Processors) or by software-implemented codec algorithms.

In order to minimize the storage space required for a complex datastream, for example audio and/or video data, the data are also regularlycompressed according to defined algorithms. To use the data, adecompression algorithm is required, which reverses the compressionafter transmission or storage. This means that each compression involvesa respective decompression which inverts precisely this compression. Thehardware and software solutions created for the above purpose are alsogenerally known as codecs. A data stream coded or compressed with aspecific codec can be decompressed only by this codec.

H.323 denotes a standard for audio-, video-,and data-communication viaan IP-based network. The H.323 set of protocols comprises the followingcodec standards for example: G. 711, G. 722, G. 723, G. 728 and G. 729,with the G.711 standard offering uncompressed transmission, as is alsoused in music CD technology and in the ISDN network. The above standardis strictly prescribed for all H.323 systems and in principle(discounting potential packet delays) it offers the best quality byvirtue of the minimal delay. The above method has a data rate of 56 Kbpsor 64 Kbps and a bandwidth of 3.1 kHz. If more powerful signalprocessors are used for coding, then the bit rates required can becompressed to 5.3 Kbps, whilst maintaining a very good speech quality.This does result in longer delays, however.

Low bandwidth requirements are desirable at the subscriber end, firstlyfor reasons of local connection technology, for example in modem lines,and secondly to avoid jams in the network. This is because the greaterthe bandwidth required, the more likely (in a given maximum bandwidth ofthe transmission path) is the probability of delayed packet deliveriesor even the loss of packets.

All the types of codec referred to above have certain advantages: G.723has the lowest bandwidth but a very high delay. G. 728 has a low delaybut still has a data rate of 16 Kbps. G.729 has an average delay and adata rate of 8 Kbps.

Further codecs are for instance MP3 (MPEG Layer III Audio) for highquality transmission of audio data on the Internet, H. 261 and H. 263for videoconferencing with low or average quality or Sorensen Video forhigh quality video data transmission over IP networks.

With the above codecs, the data are coded to reduce the storage spacerequired or to accelerate data transmission. At the receiving end, thecodec used to transmit the data must be available fordecoding/decompressing the data received, as already mentioned above.Therefore, when establishing a voice link via an IP network (VoIP) anappropriate codec has to be set both at the transmitting end and at thereceiving end of the link. The media gateways at both ends of the IPnetwork are controlled by appropriate media gateway controllers (MGCs).

In a VoIP link set-up, the above MGCs negotiate about the codec that isto be used. As the basis of negotiations, both MGCs each use anadministratively pre-established codec list. If a codec not supported byboth media gateways is then selected from this codec list the link isdisconnected.

SUMMARY OF INVENTION

The present invention therefore addresses the problem of providing animproved method of codec negotiation which is both faster and successfuleven in heterogeneous networks. Furthermore it aims to provide anappropriate device to carry out the method.

With respect to the method, the above problem is solved by providing amethod that forms the subject matter of claim 1. With respect to thedevice, the solution to the above problem is shown in claim 7.

An essential idea underlying the invention is that the media gatewaycontrollers not only carry out a negotiation for a link set-up using theadministratively pre-established codec list, but also have recourse to afurther codec list that they manage themselves, each of which listscontains the codecs actively supported by the assigned media gateway.Recourse to both codec lists, both the administratively pre-establishedlist and the active codec list is achieved such that only codecsincluded in both lists are used for negotiation. Only codecs from theintersection of both codec lists are available so to speak. Subsequentdisconnection of the link due to unsupported codecs is thus avoided. Theprocess of negotiation is accelerated because codec negotiation is nowcarried out only by the gateway controllers. The gateways themselves aremerely informed as to which codec has been negotiated.

In an advantageous embodiment of the present invention, the controllerof the receiving gateway (second gateway controller) establishes a listof the codecs that are included both in the codec list transmitted bythe controller of the transmitting gateway (first gateway controller)and in the active codec list from the second gateway controller. Theabove list is further transmitted to the first gateway controller. Bothcontrollers store the above list for the duration of the link. As aresult, both gateway controllers have at their disposal a list of codecsthat are supported by both media gateways participating in the abovelink.

In a further advantageous embodiment of the present invention, theactive codec list contains only codecs that are both currently supportedby each gateway and included in each administratively pre-establishedcodec list. This leads to a further increase in negotiation performance.The above active list may therefore contain a lower number of codecsbecause the media gateway also supports codecs that are not included inthe administratively pre-established codec list.

In a further advantageous embodiment, the management of the active codeclist is carried out in such a way that when a gateway in the networkfirst calls up, the assigned gateway controller is notified of thecodecs supported by the gateway. As a result of the above notification,the gateway controller is able to establish the active codec list.Furthermore, the gateway controller is notified of changes regarding thecodecs that are supported so that the active codec list contains therespective current status of the codecs that can be used.

In a further preferred embodiment, the gateway controller periodicallyinterrogates the gateway assigned thereto in order to maintain theactive codec list at current status in each case. Changes regarding thecodecs supported by the gateway are entered in the active codec list inthe next interrogation.

In a further advantageous embodiment, there is a switch-over to anothercodec during a link. The above codec is included in the codec listtransmitted by the second gateway controller to the first gatewaycontroller. Consequently the above codec is supported by both two mediagateways and, during a link or a data transmission, a switch-over can bemade in each case to a codec having the current most favorabletransmission parameters.

The administratively pre-established codec list preferably contains atleast the codecs referred to in the H. 323 standard. Consequently theadministratively pre-established codec list shows the codecs relevant tomost VoIP links.

Advantageous aspects of the device according to the invention come tolight in accordance with the above description of the advantageousaspects of the method according to the invention.

A preferred embodiment of the device according to the inventionadditionally has a further memory device on each side of the link, inwhich device the codec lists are stored for the duration of a link, andwhich device contains the codes that are included in the two activecodec lists and in the administratively pre-established codec lists. Theabove stored list includes so to speak the intersection of all relevantcodec lists, and a codec selected from said intersection is supported byboth ends of the link.

In a further advantageous embodiment of the device according to theinvention, in each of the gateway controllers a single physical memoryis provided, in which the various codec lists are stored. Thissimplifies the set-up of the device since only one memory unit isrequired.

BRIEF DESCRIPTION OF THE DRAWINGS

Advantages and uses of the invention also emerge from the sub-claims andfrom the following description of a preferred embodiment with the aid ofthe figures. The figures show:

FIG. 1: a device for a conventional codec negotiation and

FIG. 2 a device for a codec negotiation according to the presentinvention.

DETAILED DESCRIPTION OF INVENTION

FIG. 1 represents a device for a conventional codec negotiation andshows a transmission network 11, a link network 12 and also a receivingnetwork 13. The transmission network 11 and the link network 12 areconnected via a media gateway 14. The media gateway 14 is controlled bya gateway controller 15 assigned thereto. The controller 15 accesses adatabase 16, in which an administratively pre-established codec list isstored.

The link network 12 is linked with the receiving network 13 via afurther media gateway 17. The media gateway 17 is controlled by agateway controller 18, which itself accesses a database 19. The database19 stores an administratively pre-established codec list, which maydiffer from the codec list stored in the database 16. The gatewaycontrollers 15, 18 are connected to each other in order to carry out thecodec negotiation with each other.

The function or course of a codec negotiation is now explained belowwith the aid of the figure. When setting up a voice link between thetransmission network 11 and the receiving network 13, the two gatewaycontrollers 15, 18 negotiate about the codec that is to be used. In sucha process, the gateway controller 15 selects its preferred orprioritized codec type from the codec list stored in the database 16. Itfirst signals the above codec type using a Create Connection Request

(CRCX) to the gateway 14 which only then sets the above codec as thecodec type to be used for the link. Furthermore, the controller 15notifies the controller 18 of the complete codec list from the database16.

From the codec list that it has received, the controller 18 now selectsa codec type by comparing the codec list received with the codec listthat has been stored in the database 19. When it does this it selects,from the codec list that it has received, the codec that has the highestpriority in its administratively pre-established codec list. It notifiesthe gateway 17 of the above codec type in a Create Connection Request(CRCX).

If this codec type is accepted by the gateway 17, the controller 18notifies the gateway controller 15. If the gateway 17 does not acceptthe codec type selected by the controller 18, then the controller 18selects a further codec type and notifies the gateway 17 of the newlyselected type. This continues until a codec type has been accepted bythe gateway 17. If it fails to find a common codec type, the link isdisconnected by the receiving end. If a codec type that is not acceptedor supported by the gateway 14 is selected by the receiving end andnotified to the transmitting end, then in this case the link isdisconnected by the transmitting end.

In a homogeneous network in which all the gateways are of one type, itcan be guaranteed by correct administration of the codec lists that thesame codec types are used at the transmitting and receiving end.However, in a heterogeneous network that uses gateways from differentmanufacturers this is not guaranteed.

Furthermore when, during a voice link, there is a switch-over to afax/modem transmission, the page that recognizes the fax/modem tone willinitiate the switch-over to the fax-specific codec type and in theprocess also give notification relating to the above selected codectype. If on the other hand, the above codec is not supported, the linkis disconnected.

FIG. 2 shows a device for a codec negotiation according to theinvention, which device is essentially similar to the device shown inFIG. 1. As an addition to the device as per FIG. 1, the device shown inFIG. 2 has further databases 31 and 33, which the gateway controller 25accesses. Likewise, the gateway controller 28 accesses further databases32 and 34. Databases 31, 32 store additional codec lists known as theactive codec lists (codec cache). Here the active codec list in thedatabase 31 contains the codecs that are supported by the gateway 24,and the database 32 contains the codecs that are supported by thegateway 27. The databases 33 and 34 contain further codec lists, whichare identical. This codec list contains only the codecs that areincluded in the administratively pre-established codec list from thedatabases 26 and 29.

The codec negotiation method according to the invention is explainedbelow. In the method according to the invention, independent of a callset-up in the background, codec types are interrogated periodically bythe gateway controller 25 at the gateway 24. The codec types that aresupported by the gateway 24 are stored in the database 31 as an activecode list. In the same way, the gateway controller 28 periodicallyinterrogates the codec types at the gateway 27 in order to store theaccepted codec types as an active codec list in the database 32.Alternatively or additionally the active codec list can be establishedsuch that, when the gateway 24 or 27 first calls the network, all therespective codecs that are supported are notified to the gatewaycontroller 25 or 28. Changes in the codecs that are supported are alsonotified to the gateway controller 25 or 28. Knowledge relating to thecodec types that are supported is therefore built up and storedindividually for each gateway, independent of a call set-up.

When setting up a link, the gateway controllers 25 and 28 engage in acodec negotiation. The list that the gateway controller 25 transmits tothe gateway controller 28 is not the codec list from the database 26,but a codec list that contains only codec types that are included inboth the codec list from the database 31 and in the codec list from thedatabase 26. The gateway controller 28 therefore receives a codec listcontaining codec types that are always supported by the gateway 24. Thisavoids any subsequent disconnection of the link because a codec type isnot accepted by the gateway 24. From the codec list that it has receivedthe gateway controller 28 now selects a codec type that is likewiseincluded in the codec list of the database 32 and in the codec list ofthe database 29. Since the codec type selected is also included in theactive codec list from the database 32, it is supported by the gateway27. Both the gateway controllers 25, 28 can therefore negotiate in thecodec negotiation only with respect to codec types that are supported bythe gateways 24 and 27. This excludes the possibility of any subsequentdisconnection because a codec type is not accepted by one of said twogateways 24, 27.

In addition to the codec types that have to be signaled in the codecnegotiation for a voice link, all the available codec types aretransmitted in each case from the transmitting end to the receiving endand likewise from the receiving end to the transmitting end. The abovecodec list includes so to speak the intersections of the codec listsfrom the databases 26, 29, 31 and 32. The codec types included thereinare supported by both gateways 24 and 27. Both the gateway controllers25 and 28 store this codec list in the databases 33 and 34.

If, during a link, a switch-over is now made to a fax/modemtransmission, then each codec type can be selected by each end from theintersection codec list in the databases 33, 34. This then guaranteesthat in all cases, the call can be successfully switched over and thatthere is no disconnection.

The implementation of the invention is not restricted to the examplesthat have been described and the aspects highlighted above, but is alsopossible within the scope of the claims in a plurality of variants thatfall within the scope of normal trade practice.

1-10. (canceled)
 11. A method for codec negotiation for a datatransmission between two media gateways, comprising: linking the mediagateways via a network; controlling the media gateways by a controlunit; setting up a link between a first control unit, which is assignedto the transmitting gateway, and a second control unit, which isassigned to the receiving gateway; transmitting a codec list to thesecond control unit by the first control unit, wherein the codec list ispredetermined in the first control unit; selecting a codec from thetransmitted codec list; transmitting the selected codec to the receivinggateway by the second control unit; transmitting the selected codec fromthe second control unit to the first control unit; transmitting thetransmitted codec from the first control unit to the transmittinggateway; transmitting the data from the transmitting gateway to thereceiving gateway using the transmitted codec, wherein the control unitseach manage an active codec list of codecs that are supported by eachassigned gateway, wherein the codec list has, during the transmitting acodec list step, only codecs that are supported by the transmittinggateway, and wherein during the selecting a codec from the transmittedcodec list step, a codec is selected that is in the active codec listmanaged by the second control unit.
 12. A method according to claim 11,wherein the codec list is administratively predetermined in the firstcontrol unit.
 13. A method according to claim 11, wherein the secondcontrol unit establishes a list of codecs that are included in the codeclist transmitted by the first control unit and in the active codec listof the second control unit, and transmits the established list to thefirst control unit, and wherein the control units store the establishedlist for the duration of a link.
 14. A method according to claim 11,wherein the active codec lists comprise only codecs that are supportedboth by each gateway and are included in each predetermined codec list.15. A method according to claim 13, wherein the active codec listscomprise only codecs that are supported both by each gateway and areincluded in each predetermined codec list.
 16. A method according toclaim 1 1, wherein when a gateway first calls the network and/or whenchanges are made, the gateway notifies the respective control unit ofthe codecs that it supports.
 17. A method according to claim 13, whereinwhen a gateway first calls the network and/or when changes are made, thegateway notifies the respective control unit of the codecs that itsupports.
 18. A method according to claim 11, wherein the control unitperiodically interrogates the respective gateway assigned theretoregarding the codecs that are supported by the gateway.
 19. A methodaccording to claim 13, wherein the control unit periodicallyinterrogates the respective gateway assigned thereto regarding thecodecs that are supported by the gateway.
 20. A method according toclaim 13, wherein during a link, a switch-over is made to another codecthat is included in the codec list transmitted by the second controlunit to the first control unit.
 21. A device for performing a method forcodec negotiation for a data transmission between two media gateways,the device comprising: a transmitting gateway; a receiving gateway; afirst control unit assigned to the transmitting gateway and having afirst memory unit for storing a codec list; a second control unitassigned to the reception gateway and having a second memory unit forstoring a codec list, wherein the first and the second control unit eachhave third memory units for storing an active codec list showing thecodecs that are supported by each gateway assigned thereto, wherein themethod comprising: linking the media gateways via a network; controllingthe media gateways by a control unit; setting up a link between a firstcontrol unit, which is assigned to the transmitting gateway, and asecond control unit, which is assigned to the receiving gateway;transmitting a codec list to the second control unit by the firstcontrol unit, wherein the codec list is predetermined in the firstcontrol unit; selecting a codec from the transmitted codec list;transmitting the selected codec to the receiving gateway by the secondcontrol unit; transmitting the selected codec from the second controlunit to the first control unit; transmitting the transmitted codec fromthe first control unit to the transmitting gateway; transmitting thedata from the transmitting gateway to the receiving gateway using thetransmitted codec, wherein the control units each manage an active codeclist of codecs that are supported by each assigned gateway, wherein thecodec list has, during the transmitting a codec list step, only codecsthat are supported by the transmitting gateway, and wherein during theselecting a codec from the transmitted codec list step, a codec isselected that is in the active codec list managed by the second controlunit.
 22. A device according to claim 21, wherein the first and thesecond control unit have a fourth memory unit for storing a codec listshowing the codecs that, during a link, are included in both activecodec lists and in both the codec lists from each of the first memoryunits.
 23. A device according to claim 21, wherein in the first controlunit a physical memory is provided for each of the memory units.
 24. Adevice according to claim 21, wherein in the second control unit aphysical memory is provided for each of the memory units.
 25. A devicefor codec negotiation for a data transmission between two mediagateways, comprising: a transmitting gateway; a receiving gateway; afirst control unit assigned to the transmitting gateway and having afirst memory unit for storing a codec list; a second control unitassigned to the reception gateway and having a second memory unit forstoring a codec list, wherein the first and the second control unitscomprise a third memory unit for storing an active codec list showingthe codecs that are supported by each gateway assigned thereto.
 26. Adevice according to claim 25, wherein the first and the second controlunit each have a fourth memory unit for storing a codec list showing thecodecs that, during a link, are included in both active codec lists andin both the codec lists from each of the first memory units.